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(57) Abstract: A method for providing presence gateway functionality includes deriving presence information for subscribers in a 
first set of subscribers based on telecommunications signaling messages. The first set of subscribers includes at least one subscriber 
who is not a subscribed-to presentity. The method also includes determining whether presence status information for a subscriber in 
the first set of subscribers has changed. In response to detecting a change in presence status, it is determined whether the subscriber 
is a subscribed-to presentity. If the subscriber is a subscribed-to presentity, a presence server is notified of the change in status of the 
subscriber. 
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DESCRIPTION 

METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR 
PROVIDING PRESENCE GATEWAY FUNCTIONALITY IN A 
TELECOMMUNICATIONS NETWORK 

5 

RELATED APPLICATIONS 
This application claims the benefit of U.S. Provisional Patent Application 
Serial No. 60/552,378, filed March 11, 2004; the disclosure of which is 
incorporated herein by reference in its entirety. 

10 

TECHNICAL FIELD 
The subject matter described herein relates to methods, systems, and 
computer program products for maintaining and delivering presence 
information. More particularly, the subject matter described herein relates to 
15 methods, systems, and computer program products for providing presence 
gateway functionality for maintaining and delivering presence information in a 
telecommunications network. 

BACKGROUND ART 

20 Presence information refers to contact information concerning a entity, 

referred to as a presentity, to which other entities can subscribe in a presence 
server database. For example, if a presentity is a mobile telecommunications 
subscriber, presence information that is stored for the subscriber may include 
the current location of the subscriber and whether or not the subscriber's 

25 handset is on or off. Another entity or application may subscribe to the 
presentity by sending a subscribe message to a presence server. The 
presence server may notify the subscribing entity of the initial presence status 
of the presentity and of changes in presence status of the presentity. 

In some conventional networks that use presence protocols, a subscriber 

30 is required to have a general packet radio service (GPRS) handset with a 
presence client running on the handset in order for the presence information for 
the subscriber to be updated in the presence server database. For example, 
when a subscriber with a GPRS handset activates his or her handset in a new 
location area, the presence client on the subscriber's handset may 
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automatically send a message to the presence database indicating that the 
subscriber is located in a particular area and that the subscriber's handset is 
activated. 

Requiring that each subscriber have a presence client running on his or 
5 her handset in order for presence information to be collected prevents the 
development of universal-applicable applications that rely on presence 
information. For example, not all subscribers have GPRS handsets, not to 
mention GPRS handsets with presence clients. Accordingly, applications, such 
as SMS, push-to-talk, instant messaging, and conference calling, that rely on 

10 presence information are limited to subscribers with specialized 
communications equipment. Stated differently, because presence information 
is not available regarding all types of subscribers, including subscribers without 
GPRS handsets, the applicability of applications that rely on presence 
information is limited. 

15 Another problem with current presence implementations is that presence 

information is only maintained for subscribers who are currently subscribed to 
by other entities. If a subscriber is not currently subscribed to, presence 
information may not be stored in a presence server database for that 
subscriber. As a result, when a subscriber becomes subscribed to, there may 

20 be delay between the time that presence information is obtained and delivered 
to the subscribing entity. 

Accordingly, in light of these difficulties associated with conventional 
presence implementations, there exists a need for improved methods, systems, 
and computer program products for providing presence gateway functionality in 

25 a telecommunications network. 

SUMMARY 

According to one aspect of the subject matter described herein, a 
method for maintaining and delivering presence information regarding 
30 telecommunications network subscribers includes deriving presence information 
for a first set of telecommunications network subscribers based on 
telecommunications signaling messages relating to communications to or from 
members of the first set of subscribers. The first set of subscribers may include 
a set of potential presentities that represents subscribers who may or may not 
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be subscribed to by other entities. Based on the telecommunications signaling 
messages, it is determined whether the presence status associated with a 
subscriber in the first set has changed. In response to determining that the 
presence status has changed, it is determined whether the subscriber is a 
5 subscribed-to presentity. If the subscriber is determined to be a subscribed-to 
presentity, the presence server is notified of the change in presence status of 
the subscriber. 

Because the subject matter described herein derives and maintains 
presence information for a first set of subscribers that includes subscribed-to 

10 presentities and non-subscribed-to presentities, when a subscriber in the set 
becomes a subscribed-to presentity, the time for distributing the presence 
information to the presence server and to the subscribers or applications 
seeking information regarding the presentity is reduced. As a result, the subject 
matter described herein reduces the time required for collecting and delivering 

15 presence information over conventional presence implementations. 

The subject matter described herein for deriving and maintaining 
presence information may be implemented using hardware, software, firmware, 
or any combination thereof. In one exemplary implementation, the subject 
matter described herein may be implemented using a computer program 

20 product comprising computer executable instructions embodied in a computer 
readable medium. Exemplary computer readable media suitable for 
implementing the subject matter described herein includes chip memory 
devices, disk storage devices, application specific integrated circuits, and 
programmable logic devices. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 
Preferred embodiments of the subject matter described herein will now 
be explained with reference to the accompanying drawings of which: 

Figure 1 is a network diagram illustrating an exemplary architecture for 
30 collecting signaling messages, deriving presence information regarding 
subscribed-to presentities and non-subscribed-to presentities based on the 
signaling messages, and delivering presence information to a presence server 
according to an embodiment of the subject matter described herein; 
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Figure 2 is a flow chart illustrating exemplary steps for filtering signaling 
messages to be delivered to a presence gateway correllator according to an 
embodiment of the subject matter described herein; 

Figure 3 is a block diagram illustrating a distributed architecture for a 
5 presence gateway according to an embodiment of the subject matter described 
herein; 

Figure 4 is a block diagram illustrating exemplary functional components 
of a presence gateway according to an embodiment of the subject matter 
described herein; 

1 0 Figure 5 is a flow chart illustrating exemplary steps for deriving presence 

information for potential presentities based on ISUP messages according to an 
embodiment of the subject matter described herein; 

Figure 6 is a flow chart illustrating exemplary steps for deriving presence 
information based on SIP messages according to an embodiment of the subject 
1 5 matter described herein; 

Figure 7 is a flow chart illustrating exemplary steps for deriving presence 
information concerning potential presentities based on IS-41 messages 
according to an embodiment of the subject matter described herein; 

Figure 8 is a flow chart illustrating exemplary steps for deriving presence 
20 information concerning potential presentities based on GSM messages 
according to an embodiment of the subject matter described herein; 

Figure 9 is a flow chart illustrating exemplary steps for managing 
presence subscription information at a presence gateway according to an 
embodiment of the s.ubject matter described herein; 
25 Figure 10 is a flow chart illustrating exemplary steps that may be 

performed in managing events at a presence gateway according to an 
embodiment of the subject matter described herein; 

Figure 1 1 is a message flow diagram illustrating exemplary messages for 
transferring subscription information from a presence server to a presence 
30 gateway according to an embodiment of the subject matter described herein; 
and 

Figure 1 2 is a message flow diagram illustrating exemplary messages for 
delivering presence state information from a presence gateway to a presence 
server according to an embodiment of the subject matter described herein. 
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DETAILED DESCRIPTION OF THE INVENTION 
The subject matter described herein includes a presence gateway that 
manages potential presentity information, derives presence information from 
telecommunications signaling messages from a plurality of different nodes in 
5 the network, maintains presence information for both subscribed-to and non- 
subscribed-to presentities, and delivers presence information for subscribed-to 
presentities to a presence server. Figure 1 illustrates a telecommunications 
network including a presence gateway according to an embodiment of the 
subject matter described herein. Referring to Figure 1, the illustrated 

10 telecommunications network includes a plurality of nodes that exchange 
signaling messages in order to set up and tear down calls and send SMS 
messages. In the illustrated example, the telecommunications network includes 
mobile switching centers (MSCs) 100 and base stations 102 for enabling 
communication with wireless mobile subscribers. Similarly, serving GPRS 

15 support node (SGSN) 104 and gateway GPRS support node (GGSN) 1Q6 
enable communication with GPRS wireless mobile subscribers. A short 
message service center (SMS-C) 108 stores SMS messages and forwards the 
SMS messages to their intended destinations. A home location register (HLR) 
110 stores mobile subscription and mobile subscriber location information. 

20 A media gateway controller (MGC) 112 controls one or more nnedia 

gateways (not shown in Figure 1) for calls over packet networks. MGC 112 
also performs call setup signaling to establish and tear down voice over IP calls. 
PSTN 114 includes traditional wireline components to establish and tear down 
calls with wireline subscribers. For example, PSTN 114 may include one or 

25 more end office switches, databases, and other nodes that perform the 
signaling necessary to establish and tear down wireline calls. 

Signal transfer points 116 route signaling messages between other 
nodes in the network. For example, signaling transfer points 116 may route 
SS7 signaling messages based on SS7 point codes. Signal transfer points 116 

30 may also route IP telephony signaling messages based on IP addresses. 
Examples of I P telephony signaling messages that may be routed by STPs 116 
include SIP messages, MGCP messages, and SS7 over IP messages. 
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The nodes on the right hand side of Figure 1 perform the same functions 
as the correspondingly numbered nodes on the left hand side of Figure 1. 
Accordingly, a description thereof will not be repeated herein. One difference 
between the nodes illustrated on the right hand side of Figure 1 and the nodes 
5 illustrated on the left hand side is that on the left hand side, STPs 116 include 
integrated link monitors 118, whereas messages traversing STPs 116 on the 
right hand side are monitored through stand-alone link monitoring probes 120. 
STPs 116 having integrated link monitors 118 may include message copy 
functions located on each interface card within the STP. The message copy 

10 functions forward copies of received messages to network monitoring 
processors 118. Network monitoring processors 118 buffer message copies 
and forward the message copies to downstream applications. External network 
monitoring probes 120 include hardware and software that non-intrusively copy 
messages that traverse signaling links between various network nodes. One 

1 5 example of a commercially-available system suitable for implementing probes 
118 and 120 is the Sentinel™ system available from Tekelec of Calabasas, 
California. 

According to an aspect of the subject matter described herein, a 
presence gateway 122 receives signaling messages copied by probes 118 and 

20 120, generates presence information regarding non-subscribed-to presentities 
and subscribed-to presentities, and forwards presence information for 
subscribed-to presentities to a presence server 124. In the illustrated example, 
presence gateway 122 includes a presence gateway correlator 126 for 
correlating messages relating to the same transaction or subscriber and a 

25 presence gateway event manager 128 for notifying presence server 124 of 
changes in presence status of a subscribed-to presentity. 

Presence server 124 may receive presence status information from 
presence gateway 122 and from 2G and 3G networks 130. Presence server 
124 may also provide presence information to one or more application servers 

30 132. Application server 132 may implement one or more applications that use 
presence information. Examples of such applications may include SMS, push- 
to-talk, instance messaging, and conference calling. 
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An administration server 134 allows operators to provision a potential 
presentity database maintained by presence gateway 122. Administration 
server 134 may also allow operators to control messages collected by probes 
118 and 120. For example, administration server 134 may allow an operator to 
5 define message filters used by probes 118 and 120 to identify messages of 
interest. 

Figure 2 is a flow chart illustrating exemplary steps that may be 
performed by network monitoring probes 118 and 120 in screening signaling 
messages and forwarding the signaling messages to presence gateway 

10 correlator 126. Referring to Figure 2, in step 200, a message is received by a 
probe 118 or 120. In step 202, the probe determines the service or protocol 
type of the message. Determining the service or protocol type may include 
determining whether the message is an ISUP, IS-41 , GSM, SIP, MGCP, GPRS 
or other type of message. In step 204, it is determined whether the message is 

15 a message of interest. Determining whether the message is a message of 
interest may include comparing the determined message type to a list 206 of 
provisioned message types. List 206 may be provisioned by an operator via 
administration server 134 illustrated in Figure 1 . If the message is determined 
to be a message of interest, control proceeds to step 208 where the message is 

20 forwarded to presence gateway correlator 126. If the message is determined 
not to be a message of interest, processing ends for this message and control 
returns to step 200 where the next message received by the probe is 
processed. 

Figure 3 is a block diagram illustrating a distributed implementation of 
25 presence gateway 122. In Figure 3, presence gateway 122 includes a plurality 
of presence gateway correlators 126 connected to a single presence gateway 
event manager 128 via a LAN/WAN 300. Each presence gateway correlator 
126 receives messages of interest from probes 118 and 120. Presence 
gateway event manager 128 receives events detected by each correlator and 
30 forwards the events relating to subscribed-to presentities to presence server 
124. 

Figure 4 illustrates an exemplary architecture for presence gateway 122 
in more detail. Referring to Figure 4, presence gateway correlator 126 includes 
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a database 400 of potential presentities. As described above, potential 
presentities may include subscribed-to presentities and non-subscribed-to 
presentities representing the universe of subscribers for which a service 
provider may desire to obtain presence information. Because correlator 126 
5 stores presence information regarding potential presentities who are not 
subscribed-to presentities, the delivery of presence information regarding these 
subscribers can be expedited over conventional presence implementations 
where presence information is collected only for subscribed-to presentities. 
That is, because correlator 126 derives and caches presence information for 

10 non-subscribed-to presentities, presence information for these entities can be 
readily obtained when a subscription to one of the entities occurs. 

In the illustrated example, presence gateway correlator 126 selects and 
correlates messages where the called or calling party is a potential presentity, 
detects events regarding potential presentities, and passes the events to event 

15 manager 128. Event manager 128 includes a database 402 of subscribed-to 
presentities. Subscribed-to presentities may be subscribers whose presence 
status is currently being monitored by another subscriber or application. Entries 
in subscribed-to presentity database 402 may be dynamically updated based on 
SIP subscription messages and subscription cancellation messages from 

20 presence server 124. If an entity is a subscribed-to presentity and an event 
occurs that results in a change in presence status for a subscribed-to 
presentity, event manager 128 may send a notification to presence server 124. 

Although in the example illustrated in Figure 4, separate databases are 
shown for storing information regarding potential presentities and subscribed-to 

25 presentities, the subject matter described herein is not limited to a two- 
database implementation. In an alternate implementation, databases 400 and 
402 can be combined without departing from the scope of the subject matter 
described herein. 

One type of message for which it may be desirable to derive presence 
30 information is ISDN user part (ISUP) messages. Figure 5 is a flow chart 
illustrating exemplary steps that may be performed by presence gateway 
correlator 126 in correlating ISUP messages according to an embodiment of the 
subject matter described herein. Referring to Figure 5, in step 500, presence 
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gateway correlator 126 receives an ISUP message. In step 502, it is 
determined whether the message is an initial address message (IAM). If the 
message is IAM message, control proceeds to ^step 504 where it is determined 
whether the IAM message concerns a potential presentity. This step may be 
5 performed by comparing the calling party in the IAM message to potential 
presentities stored in database 400. If the IAM message does not concern a 
potential presentity, correlation processing for this message stops. 

If the IAM message concerns a potential presentity, control proceeds to 
step 506 where a new call object is created. The call object may be a data 

1 0 structure stored by correlator 126 relating to a cxall from the potential presentity. 
Because an IAM message represents call initiation, control proceeds to step 
508 where correlator 126 generates an off hool< event. An off hook event may 
be used to notify presence server that a subscriber is currently on the phone 
and therefore currently unable to receive other voice communications. In step 

15 510, correlator 126 communicates the off hook event to event manager 128. 

Returning to step 502, if the ISUP message is determined to be a 
message other than an IAM message, control proceeds to step 512 where it is 
determined whether the non-IAM message matches an existing IAM message. 
Determining whether a non-IAM message mate hes an existing IAM may include 

20 comparing the originating point code (OPC), destination point code (DPC), and 
circuit identifier code (CIC) to existing call objects. If the message does not 
match an existing IAM message, correlation processing stops for this message. 
If the message matches an existing IAM message, control proceeds to step 
514 where it is determined whether the message is an answer message (ANM). 

25 If the message is an answer message, control proceeds to step 51 6 where an 
answer event is generated and step 51 0 where the event is transferred to event 
manager 128. 

in step 514, if the message is determined not to be an answer message, 
control proceeds to step 518 where it is determined whether the message is a 
30 release (REL) or release complete (RLC) message. If the message is a release 
or release complete message, control proceeds to step 520 where a release 
event is generated. Control then returns to step 510 where the event is 
transferred to event manager 128. 
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Figure 6 is a flow chart illustrating exemplary steps that may be 
performed by correlator 126 in correlating SIP messages relating to a call 
origination. Referring to Figure 6, in step 600, correlator 126 receives a SIP 
message. In step 602, correlator 126 determines whether the SIP message is 
5 an INVITE message. If the message is an INVITE message, control proceeds 
to step 604 where it is determined whether the INVITE message concerns a 
potential presentity. If the INVITE message concerns a potential presentity, 
control proceeds to step 606 where a new call object is created. In step 608, 
an off-hook event is generated. In step 610, the off-hook event is 

10 communicated to event manager 128. 

In step 602, if the SIP message is determined not to be an INVITE 
message, control proceeds to step 612 where it is determined whether the 
message matches an existing INVITE message. If the message matches an 
existing INVITE message, control proceeds to step 614 where it is determined 

1 5 whether the message concerns a potential presentity. If the message concerns 
a potential presentity, control proceeds to step 616 where it is determined 
whether the message is a BYE message. If the message is a BYE message, 
control proceeds to step 618 where a release event is generated. Control then 
proceeds to step 610 where the release event is communicated to event 

20 manager 128. 

Returning to step 602, if the INVITE message is determined not to 
concern a potential presentity, correlation processing may cease for this 
message. Similarly, in step 614, if the non-INVITE SIP message is determined 
not to concern a potential presentity, control proceeds to step 620 where 

25 correlation processing ceases for the message. 

Returning to step 616, if the message is determined to not to be a BYE 
message, control proceeds to step 624 where the message is correlated with 
other messages that have been received and stored for the session. In step 
626, correlator 126 analyzes the received messages for the session for an 

30 indication of an answer event. Searching for an indication of an answer event 
may include looking for a sequence of a Ringing message from the called party 
SIP proxy to the calling party SIP proxy, a 200 OK message from the called 
party SIP proxy to the calling party SIP proxy, and an ACK message from the 

-10- 
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calling party SIP proxy to the called party SIP proxy. If this* sequence of 
messages occurs, an answer event may be indicated. If an answer event is 
indicated, control proceeds to step 628 where an answer event is generated 
and to step 610 where the answer event is communicated to event manager 
5 128. Returning to step 626, if an answer event is not indicated, control 
proceeds to step 630 where correlation processing for the message stops. 
Similarly, if in step 612 it is determined that the SIP message does not match 
an existing invite, control proceeds to step 632 where correlation processing for 
the message ceases. 

10 Another type of message for which it may be desirable to derive 

presence information includes IS-41 messages relating to registration, roaming, 
and de-activation of mobile handsets. Figure 7 is a flow chart illustrating 
exemplary steps that may be performed by presence gateway correlator 126 in 
correlating IS-41 messages and generating presence status info rmation based 

15 on the IS-41 messages. Referring to Figure 7, in step 700, oorrelator 126 
receives an IS-41 message. In step 702, it is determined whether the message 
is registration notification message. If the message is registration notification 
message, control proceeds to step 704 where it is determined whether the 
registration notification message concerns a potential presently. Determining 

20 whether the registration notification message concerns a potential presentity 
may include comparing the mobile subscriber identifier in the registration 
notification message with mobile subscriber identification information stored in 
database 400. If the registration notification message concerns a potential 
presentity, control proceeds to step 706 where a new transaction object is 

25 created. In step 708, correlator 126 generates a registration event. In step 
710, correlator 126 communicates the registration event to event manager 128. 

Returning to step 702, if the IS-41 message is determined not to be a 
registration notification message, control proceeds to step 7^12 where it is 
determined whether the IS-41 message is a location request nmessage. If the 

30 message is determined to be a location request message, control proceeds to 
step 714 where it is determined whether the location request message 
concerns a potential presentity. If the location request message concerns a 
potential presentity, control proceeds to step 716 where a new transaction 

-11- 
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object is created. In step 718, correlator 126 generates a roaming event. 
Control then proceeds to step 710 where the roaming event is transferred to 
event manager 128. 

Returning to step 712, if the message is determined not to be a location 
5 request message, control proceeds to step 720 where it is determined whether 
the message is a mobile station inactive message. If the message is 
determined to be a mobile station inactive message, control proceeds to step 
722 where it is determined whether the mobile station inactive message 
concerns a potential presentity. If the message concerns a potential presentity, 

1 0 control proceeds to step 724 where a new transaction object is created. In step 
726, correlator 126 generates a mobile off event indicating that the handset for 
the potential presentity has been deactivated. Control then proceeds to step 
710 where correlator 126 transfers the handset off event to event manager 128. 
In step 720, if the message is determined not to be a mobile station 

1 5 inactive event, correlation processing for this message ends. Similarly, in step 
722, if the message is determined not to relate to a potential presentity, 
correlation processing for the message ends. 

Yet another type of message for which it may be desirable to derive 
presence information includes GSM messages relating to registration and 

20 roaming. Figure 8 is a flow chart illustrating exemplary steps that may be 
performed by correlator 126 in generating events based on GSM messages 
according to an embodiment of the subject matter described herein. Referring 
to Figure 8, in step 800, correlator 126 receives a GSM message. In step 802, 
correlator 126 determines whether the GSM message is a location update 

25 message. If the GSM message is a location update message, control proceeds 
to step 804 where it is determined whether the message concerns a potential 
presentity. Determining whether the message concerns a potential presentity 
may include determining whether the IMSI or MSISDN number in the message 
corresponds to an IMSI or MSISDN number stored in potential presentities 

30 database 400. If the location update message concerns a potential presentity, 
control proceeds to step 806 where a new transaction object is created. In step 
808, a registration event is generated. In step 810, correlator 126 
communicates the registration event to event manager. 128. 

-12- 
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Returning to step 802, if it is determined that the GSM message is not a 
location update message, control proceeds to step 812 where it is determined 
whether the message is a send routing information (SRI) message. If the 
message is determined to be an SRI message, control proceeds to step 814 
5 where it is determined whether the SRI message concerns a potential 
presentity. Determining whether the SRI message concerns a potential 
presentity may include comparing the IMSI or MSISDN number from the SRI 
message to entries in database 400 to determine whether the IMSI or MSISDN 
matches any of the entries. If the SRI message is determined to concern a 
10 potential presentity, control proceeds to step 816 where a new transaction 
object is created. In step 818, correlator 126 generates a roaming event. In 
step 810, correlator 126 communicates the roaming event to event manager 
128. 

Returning to step 804 or step 814, if the location update or SRI message 

15 does not concern a potential presentity, control proceeds to step 820 where 
correlation processing for the message ceases. Similarly, in step 812, if it is 
determined that the message is not an SRI message or a location update 
message, correlation processing for the message ends (step 822). 

Although the example illustrated in Figure 8 includes identifying 

20 registration and roaming events based on GSM registration and location 
management messages, the subject matter described herein is not limited to 
identifying only these types of events or using only these types of messages. 
For example, similar procedures may be used to analyze mobile application 
part (MAP) or short message point to point (SMPP) messages to determine 

25 whether a potential presentity is available to receive SMS messages and the 
current location of the subscriber where the SMS messages can be delivered. 
Similarly, IS-41 messages relating to SMS delivery may be used to determine 
whether an IS-41 potential presentity is available to receive SMS messages and 
the current location of the IS-41 potential presentity where the SMS messages 

30 can be delivered. 

As stated above, event manager 128 receives subscriptions from 
presence server 124 and manages subscriptions in subscribed-to presentity 
database 402. Figure 9 is a flow chart illustrating exemplary steps that may be 
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performed by event manager 128 in managing subscriptions according to an 
embodiment of the subject matter described herein. Referring to Figure 9, in 
step 900, event manager 128 receives a subscribe message from presence 
server 124. In step 902, event manager 128 adds a subscription to subscribed- 
5 to presently database 402. In step 904, event manager 128 maps the 
subscription to the presence server that generated the subscription. 

In step 906, event manager 128 determines whether presence status 
information exists for the subscribed-to presentity. Determining whether 
presence status exists may include accessing presentity status database 404. If 

10 status information exists, control proceeds to step 908 where event manager 
128 generates a status event. In step 910, event manager 128 transfers the 
status event to presence server 124. Returning to step 906, if presence status 
information does not exist for a new subscription, control proceeds to step 912 
where an error condition is generated. The error condition may notify the 

15 operator that status information is not available for the subscriber. 

As described above, another function performed by event manager 128 
is receiving events from correlator 126 and notifying presence server 124 of 
events that relate to subscribed-to 'presentities. Figure 10 is a flow chart 
illustrating exemplary steps performed by event manager 128 in generating 

20 presence information and transferring the presence information to presence 
server 124. Referring to Figure 10, in step 1000, an incoming status event is 
detected. In step 1002, it is determined whether the status event concerns a 
potential presentity. The step of determining whether the event concerns a 
potential presentity allows event manager 128 to associate event status with 

25 potential presentities without requiring that correlator 126 communicate 
potential presentity information along with the event to event manager 128. In 
an alternate implementation, correlator 126 may communicate potential 
presentity information to event manager 128 along with each event, and step 
1002 in Figure 10 may be eliminated. If the event concerns a potential 

30 presentity, control proceeds to step 1004 where it is determined whether event 
status exists for the potential presentity. If event status exists, control proceeds 
to step 1006 where it is determined whether the status has changed. If the 
status has changed, control proceeds to step 1008 where it is determined 
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whether the status concerns a subscri bed-to presentity. If the event concerns a 
subscribed-to presentity, control proceeds to step 1010 where a status event is 
generated. In step 1012, the status event is transferred to present server 124. 
Returning to step 1002, if the status event does not concern a potential 
5 presentity, presence processing for the status event stops. In step 1004, if 
presence status does not exist for a potential presentity, control proceeds to 
step 1014 where presentity status is added to presentity status database 404. 
Storing presence status for potential presentities including presentities who are 
not currently subscribed to decreases the time for obtaining presence 

10 information when a new subscription occurs over conventional presence 
implementations. In step 1006, if it is determined that the status has not 
changed, presence event processing ceases. 

In one exemplary implementation, subscription information is transferred 
from presence server 124 to presence gateway 122 using SIP messages. 

15 Figure 11 is a flow chart illustrating exemplary SIP messages that may be 
exchanged between presence server 124 and presence gateway 122 in 
creating a new subscription. Referring to Figure 11, in line 1 of the message 
flow diagram, when an entity subscribes to a potential presentity, presence 
server 124 sends a subscribe message to presence gateway 122. In response 

20 to the subscribe message, presence gateway 122 authenticates the presence 
server. If the presence server passes the authentication, in line 2 of the 
message flow diagram, presence gateway 122 sends a SIP 200 OK message 
to presence server 124. 

In line 3 of the message flow diagram, presence gateway 122 sends a 

25 Notify message indicating the current state of the subscribed-to presentity. In 
line 4 of the message flow diagram, presence server 124 sends a 200 OK 
message to presence gateway 122 confirming receipt of the Notify message. 

As stated above, because presence gateway 122 maintains presence 
information regarding potential presentities who are not currently subscribed-to 

30 presentities, the time for obtaining status information when a potential 
presentity becomes a subscribed-to presentity is decreased over presence 
implementations where presence status information is only maintained for 
subscribed-to presentities. Using the message flow illustrated in Figure 1 1 as 
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an example, once presence gateway 122 receives a new subscription in line 1 , 
presence gateway 122 can send the Notify message in line 3 indicating the 
current state of the subscribed-to presentity without requiring that the presence 
information be obtained from the subscriber's handset. 
5 Another feature of the subject matter described herein is the 

communication between presence gateway 122 and presence server 124 when 
a change in status regarding a subscribed-to presentity occurs. In a preferred 
implementation, this communication also occurs using the SIP protocol. Figure 
12 is a message flow diagram illustrating exemplary messages that may be 

10 exchanged between presence gateway 122 and presence server 124 in 
updating presence server 124 of changes in presence status. Referring to 
Figure 12, in line 1 of the message flow diagram, when presence gateway 122 
detects a change in status of a subscribed-to presentity, presence gateway 122 
sends a Notify message to presence server 124. The Notify message includes 

15 a state change indicator indicating a new state of the subscribed-to presentity. 
For example, the state change may be communicated using an off hook event 
indicator for a subscribed-to presentity who was previously on hook. In line 2 of 
the message flow diagram, presence server 124 confirms receipt of the Notify 
message via a 200 OK message. 

20 Although the examples described above relate primarily to deriving 

presence event information based on analyzing signaling messages of each 
protocol in isolation, the subject matter described herein is not limited to 
analyzing signaling messages of each protocol in isolation. For example, in one 
exemplary implementation, presence gateway 122 may analyze signaling 

25 messages relating to GSM and GPRS procedures together to determine 
whether a registration event has occurred. Such a method may include 
determining whether a GSM location update or a GPRS location update has 
occurred using steps similar to these described above with respect to Figure 8. 
If a GPRS location update and a GPRS location update have occurred, the 

30 presence information for the subscriber may be updated to include both GPRS 
and GSM registration and location information. One advantage to using both 
GSM and GPRS procedures is that location area units for GSM are different 
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than those of GPRS. By monitoring both GSM and GPRS messages, more up- 
to-date and accurate presence information can be achieved. 

Another aspect of the subject matter described herein includes 
monitoring messages that are destined to multiple network elements, such as 
5 MSC/VLRs, HLRs, SMSCs, GMSCs, SGSNs, and GGSNs. In the architecture 
illustrated in Figure 1 , probes 118 and 120 are connected to signal links and to 
signaling nodes that are capable of collecting messages from all of these 
network elements. By monitoring messages to multiple network elements, a 
network view of presence can be obtained as opposed to a single network 

10 element view, such as an HLR view. 

Another advantage or feature of the subject matter described herein is 
that presence information is derived from messages relating to multiple 
services, such as call setup, call tear down, roaming, and location updating. 
Other services that may be monitored include SMS message delivery and 

15 failure, and supplementary services, such as call forwarding. Monitoring all of 
these services further enhances the accuracy and granularity of presence 
information. For example, if an SMS message is determined to be 
undeliverable, the presence status for a subscriber may be set to unreachable 
for receiving text messages. 

20 As illustrated in Figure 1, in one exemplary implementation, presence 

information is derived from signaling messages at an STP. Deriving presence 
information from signaling messages that traverse an STP is advantageous 
because the solution will work with existing handsets without requiring 
modifications of the handset or other devices to include presence clients. In 

25 addition, the presence information collected at an STP is more accurate than 
information collected using a single network element, such an HLR or a GPRS 
node. In addition, since STPs now include IP communications capabilities, 
presence information can be obtained with requiring direct access to HLR 
devices using SS7 protocols. 

30 One disadvantage to deriving presence information based on signaling 

messages that traverse an STP is that the STP may not have visibility for intra- 

MSC, non-roaming calls. Similarly, in wireline networks, the STP does not have 

visibility for calls that involve a single switch or calls between switches that have 

direct signaling connections. In these cases, probes may be placed at the 
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switches to detect the signaling messages associated with these calls. In 
another example, an STP may not have visibility for PDP context related 
protocol exchange between an SGSN and GGSN. Accordingly, as illustrated in 
Figure 1 , probes 120 are connected to both SGSN 104 and GGSN 106 to avoid 
5 this difficulty. 

According to another aspect of the subject matter described herein, 
presence information may be maintained for multiple identities of a subscriber. 
For mobile network subscribers, the identities may include IMSIs, MSISDN 
numbers, and subscriber email addresses. For landline subscribers, the 
10 presence information may include subscriber directory numbers and routing 
numbers for ported subscribers. 

Analysis of signaling messages of one or more protocols may be used to 
derive high level presence information, such as voice communications 
availability, in addition to network presence. For example, ISUP or SIP call 
15 setup and/or call tear down signaling messages may be used to determine 
whether a potential presentity is available to receive voice communications in 
addition to network presence. 

The examples described above relate to monitoring many types of 
messages to derive presence information. The following list illustrates some of 
20 those messages and additional messages that may be monitored by presence 
gateway 122 to derive presence information. All of the following messages 
have a corresponding RESULT message in the opposite direction. Monitoring 
of the RESULT message may also be performed though not explicitly 
referenced below. 

25 

MAP/D UPDATE LOCATION - from VLR to HLR 

Note: Initiated when subscriber turns on phone or changes location for GSM 
Services. The result will indicate if the Registration is accepted or 
rejected. 

30 

MAP/D CANCEL LOCATION - HLR to old VLR 

Note: Indicates that subscriber has moved to a new GSM location and old VLR 
must remove the subscriber from its records. 
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MAP/D INSERT SUBSCRIBER DATA - from HLR to VLR 
Note: Subscriber related data is downloaded to VLR to synchronize VLR and 
HLR view of the subscriber status. 

5 

MAP/D DEREGISTER MOBILE SUBSCRIBER - VLR to HLR 
Note: Sparingly used. 

MAP/D SEND PARAMETERS - VLR to HLR 
10 Note: Requesting IMSI and authenticating triplets. 

MAP/G SEND Parameters - from new MSC to previous MSG 
Note: To request IMSI and authenticate triplets. 

15 MAP/D PROVIDE ROAMING NUMBER - from HLR to VLR 

Note: An incoming call to the GMSC (from outside the network) triggers the 
event. 

MAP/C SEND ROUTING INFORMATION - from GMSC to HLR 
Note: An incoming call to the GMSC (from outside the network) triggers this 
20 event. 

MAP/C Send Routing Info for SM - from SMS gateway to HLR 
Note: An incoming short message triggers this message. 

25 MAP/C SET MESSAGE - Waiting data result, from SMS gateway to HLR 

Note: Indicates that the SMS message was not delivered because it was 
unreachable. 

MAP/D Note MS PRESENT - from MSC to HLR 
30 Note: After not able to deliver a SM, if the MSC/VLR identifies the presence of 
the mobile subscriber, this message is sent. 

MAP/C ALERT SERVICE CENTER - from HLR top SMS Gateway: 



-19- 



WO 2005/086966 



PCT/US2005/008258 



Note: This is an alert from HLR to SMS gateway to resend the message 
indicating that an earlier unavailable subscriber has now become 
available. 

5 MAP/H - FORWARD SHORT MESSAGE - from MSC to SMS-C 

Note: This indicates a MO SM and is used to identify the mobile as present. 
IS UP Messages: 

Indicate the presence status of originating and terminating subscriber. 

10 I AM 
ACM 
ANW 
REL/RLC 

15 Note: ISUP messages can be used to obtain the presence status of both 
originating and terminating subscriber. They can also be used to obtain 
higher level presence information, such as information indicating that 
subscriber is in a call. However there are cases where STP may not see 
an ISUP messages, such as intra-MSC, non-roaming call. In such 

20 cases, probes located at the switch or MSC may be used to collect 

messages used to derive presence information. 

MAP/D UPDATE LOCATION - from SGSN to HLR 

Note: Initiated when subscriber turns on phone or changes location for GPRS 
25 services. The result will indicate if the registration is accepted or 

rejected. 

MA/D INSERT SUBSCRIBER DATA - from HLR to SGSN 
Note: Subscriber related data is downloaded to SGSN to synchronize SGSN & 
30 HLR view of the subscriber status. 

SEND AUTHENTICATION INFO - from SGSN to AuC 
Note: To get authentication triplet for an IMSI 
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SGSN CONTEXT REQUEST/RESPONSE/ACK- from new SGSN to old SGSN 
Note: This event results because of a Routing Area Update of the GPRS 
handset from old SGSN to a new SGSN. 

5 MAP/D CANCEL LOCATION - HLR to old SGSN 

Note: Sent for HLR to old SGSN as a result of GPRS subscriber updating 
Routing Area. 

LNP Query and Responses: 
1 0 These indicate the availability of the subscriber. 

Call Forwarding Implications: 

Subscriber has activated call forwarding (unconditional or unreachable). 

1 5 It will be understood that various details of the invention may be changed 

without departing from the scope of the invention. Furthermore, the foregoing 
description is for the purpose of illustration only, and not for the purpose of 
limitation, as the invention is defined by the claims as set forth hereinafter. 
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CLAIMS 

What is claimed is: 

1 . A method for maintaining and delivering presence information regarding 
telecommunications network subscribers, the method comprising: 

5 (a) deriving presence information for a first set of 

telecommunications network subscribers based on 
telecommunications signaling messages relating to 
communications to or from members of the first set of 
subscribers, the first set of subscribers including at least one 
10 subscriber who is not currently subscribed to in a presence 

database; 

(b) determining whether presence status associated with a first 
subscriber in the first set of subscribers has changed based on 
the presence information derived for the first subscriber; 
15 (c) in response to determining that the presence status associated 

with the first subscriber has changed, determining whether the 
first subscriber is a subscribed-to presentity; and 
(d) in response to determining that the first subscriber is a 
subscribed-to presentity, notifying a presence server of the 
20 change in presence status of the first subscriber. 

2. The method of claim 1 wherein deriving presence information comprises: 

(a) receiving telecommunications signaling messages associated 
with a plurality of subscribers; 

(b) identifying predetermined signaling messages from which 
25 presence information may be derived; 

(c) from the predetermined signaling messages, identifying 
messages that contain identifying information associated with 
subscribers in the first set of subscribers; and 

(d) based on the signaling messages containing identifying 
30 information associated with subscribers in the first set of 

subscribers, generating presence status events for the 
subscribers in the first set of subscribers. 
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3. The method of claim 2 wherein identifying predetermined signaling 
messages from which presence information may be derived includes 
identifying predetermined PSTN call signaling messages. 

4. The method of claim 2 wherein identifying predetermined signaling 
5 messages from which presence information may be derived includes 

identifying predetermined mobile signaling messages. 

5. The method of claim 2 wherein identifying predetermined signaling 
messages includes identifying predetermined IP telephony signaling 
messages. 

10 6. The method of claim 2 wherein identifying predetermined signaling 
messages includes identifying GSM and GPRS signaling messages and 
wherein generating presence status events includes generating the 
presence status events based on the GSM and GPRS signaling 
messages. 

1 5 7. The method of claim 2 wherein identifying signaling messages includes 
collecting signaling messages that do not traverse a signal transfer point 
(STP) and wherein generating presence status events includes 
generating the presence status events for the signaling messages that 
do not traverse the STP. 

20 8. The method of claim 2 wherein identifying signaling messages includes 
collecting signaling messages destined for a plurality of different network 
elements and wherein generating presence status events includes 
generating presence status events based on the collected call signaling 
messages. 

25 9. The method of claim 2 wherein generating presence status events 
includes generating a registration event for a mobile subscriber in 
response to receiving a mobile call signaling message indicating 
registration of the mobile subscriber. 

10. The method of claim 2 wherein generating presence status events 
30 includes generating a roaming event in response to receiving a mobile 

signaling message indicating that a mobile subscriber is roaming. 

11. The method of claim 2 wherein generating presence status events 
includes generating a handset off event in response to receiving a 
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signaling message indicating that a mobile subscriber has deactivated a 
mobile handset. 

12. The method of claim 1 wherein deriving presence information for a first 
set of telecommunications network subscribers includes maintaining a 

5 first database of potential presentities and continuously deriving and 

storing presence information for the potential presentities. 

13. The method of claim 12 wherein determining whether the first subscriber 
is a subscribed-to presentity includes maintaining a second database of 
subscribed-to presentities representing a second set of subscribers 

10 different from the first set of subscribers and determining whether the 

first subscriber is present in the second database. 

1 4. The method of claim 1 2 wherein maintaining a first database of potential 
presentities includes maintaining a plurality of identities for at least one 
of the potential presentities. 

15 15. A method for deriving high-level presence information based on received 
signaling messages, the method comprising: 

(a) receiving a plurality of signaling messages; 

(b) screening, from the signaling messages, at least one of call setup 
and call tear down messages regarding a subscribed-to 

20 presentity; 

(c) deriving, from the at least one of call setup and call tear down 
messages regarding the subscribed-to presentity, network 
location and voice communication availability information; and 

(d) forwarding the network location and voice communication 
25 availability information to a presence server. 

16. A method for storing presence information on behalf of a presence 
server, the method comprising: 

(a) deriving presence information for a subscriber based on signaling 

messages relating to the subscriber; 
30 (b) storing the presence information for the subscriber in a database 

separate from a presence server; 
(c) determining whether a change in presence status has occurred 

for the subscriber; and 
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(d) in response to determining that a change in presence status has 
occurred, communicating the presence information for the 
subscriber to the presence server. 

17. A method for communicating presence information to a presence server, 
5 the method comprising: 

(a) deriving presence information for a subscriber based on signaling 
messages concerning the subscriber; 

(b) receiving a subscription request from a presence server for 
obtaining presence information regarding the subscriber; and 

10 (c) in response to the subscription request, communicating the 

presence information to the presence server. 

18. The method of claim 17 comprising continuously deriving presence 
information for the subscriber and automatically updating the presence 
server in response to detecting changes in the presence information. 

15 19. A presence server gateway comprising: 

(a) a presence gateway correlator for receiving telecommunications 
signaling messages, for determining whether the 
telecommunications signaling messages are associated with 
subscribers in a first group of subscribers, the first group of 

20 subscribers including at least one subscriber who is not currently 

subscribed to in a presence database and for generating 
presence status events based on the signaling messages 
associated with the subscribers in first group of subscribers; and 

(b) an event manager operatively associated with the presence 
25 gateway correlator for receiving the presence status events from 

the message correlator, for determining whether the presence 

status events are associated with subscribed-to presentities, and, 

in response to determining that the events are associated with 

subscribed-to presentities, for communicating the presence 

30 status events to a presence server. 

20. The gateway of claim 19 wherein the presence gateway correlator is 

adapted to continuously derive presence information for subscribers in 

the first group of subscribers based on PSTN call signaling messages 

received for subscribers in the first group of subscribers. 
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21. The gateway of claim 19 wherein the presence gateway correlator is 
adapted to continuously derive presence information for subscribers in 
the first group of subscribers based on mobile signaling messages 
relating to subscribers in the first group of subscribers. 
5 22. The gateway of claim 19 wherein the presence gateway correlator is 
adapted to generate registration events in response to detecting 
registration of a subscriber in the first group of subscribers. 

23. The gateway of claim 19 wherein the event manager is adapted to 
generate a roaming event in response to detecting roaming of a 

1 0 subscriber in the first group of subscribers. 

24. The gateway of claim 19 wherein the message correlator is adapted to 
generate handset off event in response to detecting deactivation of a 
handset of a subscriber in the first group of subscribers. 

25. The gateway of claim 19 wherein the presence gateway correlator is 
1 5 adapted to receive GSM and GPRS messages regarding subscribers in 

the first group and to generate a presence status event based on the 
GSM and GPRS messages. 

26. The gateway of claim 19 wherein the presence gateway correlator is 
adapted to receive signaling messages that do not traverse a signal 

20 transfer point (STP) and to generate the events based on the signaling 

messages that do not traverse the STP. 

27. The gateway of claim 19 wherein the presence gateway correlator is 
adapted to receive signaling messages destined for a plurality of 
different network nodes and to generate the presence information based 

25 on the signaling messages received from the different network nodes. 

28. The gateway of claim 19 comprising a potential presentities database 
accessible by the message correlator for identifying members of the first 
group of subscribers. 

29. The gateway of claim 28 wherein the potential presentities database 
30 includes at least one entry storing multiple identities for a subscriber. 

30. The gateway of claim 19 comprising a subscribed-to presentities 

database accessible by the event manager for storing information usable 

by the event manager for indicating whether a presence status event is 

associated with a subscribed-to presentity. 
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31 . A system for communicating presence information to a presence server, 
the system comprising: 

(a) a plurality of probes for collecting signaling message regarding a 
subscriber; 

5 (b) a presence gateway for receiving the signaling message, for 

deriving presence information for the subscriber based on the 
signaling messages concerning the subscriber, for receiving a 
subscription request from a presence server for obtaining 
presence information regarding the subscriber, and, in response 
10 to the subscription request, for communicating the presence 

information to the presence server. 

32. The system of claim 31 wherein the presence gateway is adapted to 
continuously derive presence information for the subscriber and to 
automatically update the presence server in response to detecting 

15 changes in the presence information. 

33. A computer program product comprising computer executable 
instructions embodied in a computer readable medium for performing 
steps comprising: 

(a) analyzing a plurality of telecommunications signaling messages; 
20 (b) from the signaling messages, identifying messages concerning 

subscribed-to presentities and non-subscribed-to presentities; 

(c) deriving presence status information regarding the subscribed-to 
presentities based on the signaling messages identified as 
concerning the subscribed-to presentities and communicating the 

25 presence status information to a presence server; and 

(d) deriving presence status information for the non-subscribed-to 
presentities based on the signaling messages identified as 
concerning the non-subscribed-to presentities and storing the 
presence status information in a database separate from the 

30 presence server. 

34. The computer program product of claim 33 comprising receiving a 
subscribe message from a presence server for subscribing to one of the 
non-subscribed-to presentities, and, in response: 
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extracting presence status information from the database for the 
presentity identified in the subscribe message; and 
communicating the presence status information to the presence 
server. 
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